2021-0426-ARCUS
ARCUS: Symbolic Root Cause Analysis of Exploits in Production Systems
作者：Carter Yagemann, Matthew Pruett, Simon P. Chung, Kennon Bittick, Brendan Saltaformaggio, Wenke Lee
单位：Georgia Institute of Technology, Georgia Tech Research Institute
会议：USENIX Security 2021
链接：https://www.usenix.org/system/files/sec21fall-yagemann.pdf
Introduction
生产环境中常使用runtime monitors（e.g. IDS）来检测是否受到攻击并予以阻止。runtime monitors常使用控制流完整性保护（CFI）、异常事件检测（system calls、segmentation faults）检测可能的攻击。然而这些runtime monitors是通过检测攻击发生后的“症状”从而对攻击进行防御，而非漏洞的root cause。例如CFI monitor检测的是非法的控制流转移，而不是code pointer第一次被corrupt的位置；部分host-based IDS检测的是不寻常的系统调用序列，而不关心程序行为是否符合预期。
虽然检测攻击现象比检测root cause简单，但是可能会导致一些问题（input filters/CFI不完整、选择性加固、大量的插桩）。而且对于程序开发者而言，获取到runtime monitors提供的snapshot后，分析漏洞的root cause仍然是一个棘手的问题。
因此，作者在runtime monitor之上设计了一个进行自动化分析root cause的框架，ARCUS。ARCUS使用假设检验的方式检测是否存在特定的检查，并使用硬件辅助机制，以降低其开销。
作者对ARCUS进行了评估，针对20个程序中的31个漏洞以及RIPE、Juliet测试集中超过9000个test case均能准确识别root cause（0漏报0误报），甚至发现了4个0 day。
Overview
Real-World Example
Threat Model
- 针对user program的攻击，kernel和hardware是可信的
- 依赖Intel PT，不会改变user program
- 针对于production system的攻击，而非直接分析
- 专注于binary，不考虑源码及调试信息
- 暂时处理不了data-only attack，后续工作时考虑
Design
- kernel module 保存程序的初始快照并通过PT收集后续的control flow
- 当runtime monitor（作者使用的CFI monitor和segmentation fault handler）检测到攻击行为发生时，将数据传给在另一台服务器上的analysis system。
- analysis system利用符号执行重构可能的data flows，并使用各种bug checker进行检查
- 考虑“what if”问题以自动化发现vulnerable state的约束状态
- ARCUS自动化给出建议的修复方案
Symbolic Execution Along Traced Paths
在monitor发出警报、analysis system收到snapshot和trace后，ARCUS将会沿着trace的路径符号化，从而避免了符号执行最大的缺点（状态爆炸）。ARCUS将将攻击者可以控制的所有输入数据（命令行参数、环境变量、文件、sockets、其他的标准I/O）进行符号化，仅对trace的路径建立约束。
“What If” Questions
对符号化的数据进行推断，ARCUS将考虑“what if”问题，这是作者工作的创新点之一。“what if”问题是用来自动化生成patch的建议。
在下图的例子中，hname为攻击者可控输入（符号量），ret_ptr为指向返回值的指针（concrete constants）。当ARCUS定位到ret_ptr被覆盖成符号的上一个状态（hname+257）时，发现存在另一条路径能够使得循环能够更早的结束，考虑“What if this path were to be taken by the program?”这个问题，即需要避免程序继续循环，则此时就对各变量产生了新的约束（cp<hname+257, hname[257]==’]’），ARCUS会将产生的约束反馈给开发人员以指导他们进行修复。
Analysis Modules
ARCUS中使用多种类型的vulnerability modules来检测以下几种类型的漏洞。
Stack & Heap Overflow
由于作者只考虑会劫持控制流的情况，DOP不在考虑范围内。
控制流被劫持时，PC会被修改为符号量，因此ARCUS寻找root cause的步骤为：
- 检测出变成符号量的code pointer
- 通过后向污点分析识别出改写它的basic block（write block/blame state）
- 寻找能够控制进入write block的basic blocks（control dependency graph (CDG)）
- 测试在这些块上添加约束条件是否能够避免bug发生
报告：blame state以及需要添加的新约束条件
Integer Overflow & Underflow
检测Integer Overflow & Underflow需要克服两个关键问题：1）在没有符号/类型信息的情况下推断寄存器/memory values为有符号数/无符号数；2）避免开发者/编译器有意的进行overflow所带来的误报。
1）使用指令的语义信息（符号扩展）以及库函数的参数类型以进行保守的推断。
2）当ARCUS发现有寄存器overflow时并不会立即report，而是当这个值传递跨越函数边界时才会report。因为作者认为接收该值的函数并不会考虑其是否为oveflowed integers。
报告：overflow发生的语句（Line 3），以及跨越函数边界的语句（Line 7），并建议对tdir_count进行额外的约束。
Use After Free & Double Free
作者假设已知所有的allocation and free function，并对其进行监控。维护allocation list和freed list，在每一次内存访问及free调用时，检查地址是否在freed list当中。
报告：Address, size, and offset以及freeing和violating basic block。
Format String
检查进入格式化字符串函数时的格式化字符串是否包含符号量、参数是否都指向合法地址。
报告：符号化的格式化字符串、漏洞位置。
Capturing the Executed Path
ARCUS通过Intel PT获取程序的trace，Intel PT对于branch会记录take or not take；间接跳转/调用、中断、异常会记录目的地址；动态生成的代码也会被记录下来。
但是对于下图的指令，Intel PT为了性能考虑并不会记录实际执行次数，故需要符号执行时需指定不同的策略。
Performance Constraints
出于性能考虑，运行一段时间后会抛弃原来的快照及trace，重新生成快照、trace。
但是由于截断，可能导致漏报。
Evaluation
Experimental Setup & Runtime Monitor Selection
- Intel ® Core ™ i7-7740X processor, 32GB of memory
- runtime monitor选择一款开源的CFI、自己实现的segmentation fault handler
Accuracy on Micro-Benchmarks
使用RIPE benchmark（包含stack、heap、integer overflow）、NIST C\C++ Juliet 1.3 suite（UAF、Double Free、format string）
结果：0 FP、0 FN。作者分析称原因是一个漏洞能够在多个位置检测出overflow，例如一个整数溢出可以在整数溢出时被检测出来，也可以在其覆盖返回地址时被检测出来。将vulnerability modules拆分开会出现一定的漏报。
Locating Real-World Exploits
选取了20个程序中的27个漏洞，使用POC进行测试。全部都能准确识别出root cause，并额外发现了4个0day。
Conclusion
本文介绍了一种借助runtime monitor和硬件PT机制，利用符号执行的方式来寻找漏洞的root cause的工作ARCUS。ARCUS能够高效准确的根据snapshot和trace识别出root cause，并通过大量的例子验证其鲁棒性。